TypeScript Authentication: รูปแบบความปลอดภัยของชนิดข้อมูล JWT สำหรับแอปพลิเคชันทั่วโลก

ในโลกที่เชื่อมโยงถึงกันในปัจจุบัน การสร้างแอปพลิเคชันทั่วโลกที่ปลอดภัยและเชื่อถือได้เป็นสิ่งสำคัญยิ่ง การยืนยันตัวตน ซึ่งเป็นกระบวนการตรวจสอบตัวตนของผู้ใช้ มีบทบาทสำคัญในการปกป้องข้อมูลที่ละเอียดอ่อนและการรับรองการเข้าถึงที่ได้รับอนุญาต JSON Web Tokens (JWTs) ได้กลายเป็นตัวเลือกยอดนิยมสำหรับการนำการยืนยันตัวตนไปใช้ เนื่องจากความเรียบง่ายและความสามารถในการพกพา เมื่อรวมกับระบบชนิดข้อมูลที่ทรงพลังของ TypeScript การยืนยันตัวตนด้วย JWT สามารถทำให้แข็งแกร่งและดูแลรักษาได้ง่ายยิ่งขึ้น โดยเฉพาะอย่างยิ่งสำหรับโครงการขนาดใหญ่ระดับนานาชาติ

เหตุใดจึงใช้ TypeScript สำหรับการยืนยันตัวตนด้วย JWT?

TypeScript นำข้อได้เปรียบหลายประการมาใช้ในการสร้างระบบการยืนยันตัวตน:

• ความปลอดภัยของชนิดข้อมูล (Type Safety): การกำหนดชนิดข้อมูลแบบคงที่ของ TypeScript ช่วยให้ตรวจจับข้อผิดพลาดได้ตั้งแต่เนิ่นๆ ในกระบวนการพัฒนา ลดความเสี่ยงจากปัญหาที่เกิดขึ้นขณะรันไทม์ ซึ่งมีความสำคัญอย่างยิ่งสำหรับส่วนประกอบที่เกี่ยวข้องกับความปลอดภัย เช่น การยืนยันตัวตน
• การดูแลรักษาโค้ดที่ดีขึ้น: ชนิดข้อมูลให้สัญญาและเอกสารที่ชัดเจน ทำให้ง่ายต่อการทำความเข้าใจ แก้ไข และปรับปรุงโค้ด โดยเฉพาะอย่างยิ่งในแอปพลิเคชันทั่วโลกที่ซับซ้อนซึ่งอาจมีนักพัฒนาหลายคนเข้ามาเกี่ยวข้อง
• การเติมโค้ดอัตโนมัติและเครื่องมือที่ดียิ่งขึ้น: IDE ที่รองรับ TypeScript มีเครื่องมือเติมโค้ดอัตโนมัติ การนำทาง และการปรับปรุงโค้ดที่ดีกว่า ช่วยเพิ่มประสิทธิภาพการทำงานของนักพัฒนา
• ลดโค้ดซ้ำซ้อน: คุณสมบัติเช่นอินเทอร์เฟซ (interfaces) และโครงสร้างทั่วไป (generics) สามารถช่วยลดโค้ดซ้ำซ้อนและปรับปรุงการนำโค้ดกลับมาใช้ใหม่

ทำความเข้าใจ JWTs

JWT คือวิธีการที่กระชับและปลอดภัยสำหรับการ URL ในการแสดงการอ้างสิทธิ์ (claims) ที่จะถูกถ่ายโอนระหว่างสองฝ่าย ประกอบด้วยสามส่วน:

1. Header: ระบุอัลกอริทึมและประเภทโทเค็น
2. Payload: มีการอ้างสิทธิ์ เช่น ID ผู้ใช้ บทบาท และเวลาหมดอายุ
3. Signature: รับรองความสมบูรณ์ของโทเค็นโดยใช้คีย์ลับ

JWT มักใช้สำหรับการยืนยันตัวตน เนื่องจากสามารถตรวจสอบได้ง่ายที่ฝั่งเซิร์ฟเวอร์โดยไม่ต้องสอบถามฐานข้อมูลทุกครั้งที่ร้องขอ อย่างไรก็ตาม การจัดเก็บข้อมูลที่ละเอียดอ่อนโดยตรงในส่วน Payload ของ JWT โดยทั่วไปไม่แนะนำ

การนำการยืนยันตัวตนด้วย JWT ที่ปลอดภัยด้วยชนิดข้อมูลไปใช้ใน TypeScript

เรามาสำรวจรูปแบบบางอย่างสำหรับการสร้างระบบการยืนยันตัวตนด้วย JWT ที่ปลอดภัยด้วยชนิดข้อมูลใน TypeScript

1. การกำหนดประเภท Payload ด้วย Interfaces

เริ่มต้นด้วยการกำหนดอินเทอร์เฟซที่แสดงโครงสร้างของ JWT Payload ของคุณ สิ่งนี้จะทำให้แน่ใจว่าคุณมีความปลอดภัยของชนิดข้อมูลเมื่อเข้าถึงการอ้างสิทธิ์ภายในโทเค็น

interface JwtPayload {
  userId: string;
  email: string;
  roles: string[];
  iat: number; // Issued At (timestamp)
  exp: number; // Expiration Time (timestamp)
}

อินเทอร์เฟซนี้กำหนดรูปร่างที่คาดหวังของ JWT Payload เราได้รวมการอ้างสิทธิ์ JWT มาตรฐานเช่น `iat` (ออกเมื่อ) และ `exp` (เวลาหมดอายุ) ซึ่งมีความสำคัญอย่างยิ่งต่อการจัดการความถูกต้องของโทเค็น คุณสามารถเพิ่มการอ้างสิทธิ์อื่นใดที่เกี่ยวข้องกับแอปพลิเคชันของคุณ เช่น บทบาทผู้ใช้หรือสิทธิ์การเข้าถึง เป็นแนวทางปฏิบัติที่ดีในการจำกัดการอ้างสิทธิ์ให้มีเฉพาะข้อมูลที่จำเป็นเท่านั้น เพื่อลดขนาดโทเค็นและปรับปรุงความปลอดภัย

ตัวอย่าง: การจัดการบทบาทผู้ใช้ในแพลตฟอร์มอีคอมเมิร์ซทั่วโลก

พิจารณาแพลตฟอร์มอีคอมเมิร์ซที่ให้บริการลูกค้าทั่วโลก ผู้ใช้ที่แตกต่างกันมีบทบาทที่แตกต่างกัน:

• ผู้ดูแลระบบ (Admin): เข้าถึงได้เต็มที่ในการจัดการผลิตภัณฑ์ ผู้ใช้ และคำสั่งซื้อ
• ผู้ขาย (Seller): สามารถเพิ่มและจัดการผลิตภัณฑ์ของตนเองได้
• ลูกค้า (Customer): สามารถเรียกดูและซื้อผลิตภัณฑ์ได้

อาร์เรย์ `roles` ใน `JwtPayload` สามารถใช้เพื่อแสดงบทบาทเหล่านี้ คุณสามารถขยายพร็อพเพอร์ตี้ `roles` ให้เป็นโครงสร้างที่ซับซ้อนขึ้น ซึ่งแสดงถึงสิทธิ์การเข้าถึงของผู้ใช้ในลักษณะที่เป็นขั้นสูง เช่น คุณอาจมีรายการประเทศที่ผู้ใช้ได้รับอนุญาตให้ดำเนินการในฐานะผู้ขาย หรือรายการร้านค้าที่ผู้ใช้มีสิทธิ์ผู้ดูแลระบบ

2. การสร้าง Typed JWT Service

สร้างบริการที่จัดการการสร้างและตรวจสอบ JWT บริการนี้ควรใช้อินเทอร์เฟซ `JwtPayload` เพื่อให้แน่ใจถึงความปลอดภัยของชนิดข้อมูล

import jwt from 'jsonwebtoken';

const JWT_SECRET = process.env.JWT_SECRET || 'your-secret-key'; // จัดเก็บอย่างปลอดภัย!

class JwtService {
  static sign(payload: Omit, expiresIn: string = '1h'): string {
    const now = Math.floor(Date.now() / 1000);
    const payloadWithTimestamps: JwtPayload = {
        ...payload,
        iat: now,
        exp: now + parseInt(expiresIn) * 60 * 60,
    };
    return jwt.sign(payloadWithTimestamps, JWT_SECRET);
  }

  static verify(token: string): JwtPayload | null {
    try {
      const decoded = jwt.verify(token, JWT_SECRET) as JwtPayload;
      return decoded;
    } catch (error) {
      console.error('JWT verification error:', error);
      return null;
    }
  }
}

บริการนี้มีสองเมธอด:

• `sign()`: สร้าง JWT จาก Payload จะรับ `Omit` เพื่อให้แน่ใจว่า `iat` และ `exp` ถูกสร้างขึ้นโดยอัตโนมัติ สิ่งสำคัญคือต้องจัดเก็บ `JWT_SECRET` อย่างปลอดภัย โดยใช้ตัวแปรสภาพแวดล้อม (environment variables) และโซลูชันการจัดการความลับ (secrets management solution)
• `verify()`: ตรวจสอบ JWT และส่งคืน Payload ที่ถอดรหัสแล้วหากถูกต้อง หรือ `null` หากไม่ถูกต้อง เราใช้การยืนยันชนิดข้อมูล `as JwtPayload` หลังจากการตรวจสอบ ซึ่งปลอดภัยเพราะเมธอด `jwt.verify` จะโยนข้อผิดพลาด (จับได้ในบล็อก `catch`) หรือส่งคืนออบเจกต์ที่ตรงกับโครงสร้าง Payload ที่เรากำหนด

ข้อควรพิจารณาด้านความปลอดภัยที่สำคัญ:

• การจัดการคีย์ลับ: ห้ามฮาร์ดโค้ดคีย์ลับ JWT ของคุณในโค้ดของคุณ ใช้ตัวแปรสภาพแวดล้อมหรือบริการจัดการความลับโดยเฉพาะ หมุนเวียนคีย์เป็นประจำ
• การเลือกอัลกอริทึม: เลือกอัลกอริทึมการลงนามที่แข็งแกร่ง เช่น HS256 หรือ RS256 หลีกเลี่ยงอัลกอริทึมที่อ่อนแอ เช่น `none`
• การหมดอายุของโทเค็น: ตั้งค่าเวลาหมดอายุที่เหมาะสมสำหรับ JWT ของคุณเพื่อจำกัดผลกระทบของโทเค็นที่ถูกบุกรุก
• การจัดเก็บโทเค็น: จัดเก็บ JWT อย่างปลอดภัยที่ฝั่งไคลเอ็นต์ ตัวเลือก ได้แก่ คุกกี้ HTTP-only หรือ local storage พร้อมมาตรการป้องกันที่เหมาะสมจากการโจมตี XSS

3. การป้องกัน Endpoint API ด้วย Middleware

สร้าง Middleware เพื่อป้องกัน Endpoint API ของคุณโดยการตรวจสอบ JWT ในส่วนหัว `Authorization`

import { Request, Response, NextFunction } from 'express';

interface RequestWithUser extends Request {
  user?: JwtPayload;
}

function authenticate(req: RequestWithUser, res: Response, next: NextFunction) {
  const authHeader = req.headers.authorization;

  if (!authHeader) {
    return res.status(401).json({ message: 'Unauthorized' });
  }

  const token = authHeader.split(' ')[1]; // สมมติว่าเป็น Bearer token
  const decoded = JwtService.verify(token);

  if (!decoded) {
    return res.status(401).json({ message: 'Invalid token' });
  }

  req.user = decoded;
  next();
}

export default authenticate;

Middleware นี้จะดึง JWT จากส่วนหัว `Authorization` ตรวจสอบด้วย `JwtService` และแนบ Payload ที่ถอดรหัสไว้กับออบเจกต์ `req.user` เรายังกำหนดอินเทอร์เฟซ `RequestWithUser` เพื่อขยายอินเทอร์เฟซ `Request` มาตรฐานจาก Express.js โดยเพิ่มพร็อพเพอร์ตี้ `user` ที่มีชนิดข้อมูล `JwtPayload | undefined` สิ่งนี้ให้ความปลอดภัยของชนิดข้อมูลเมื่อเข้าถึงข้อมูลผู้ใช้ในเส้นทางที่ได้รับการป้องกัน

ตัวอย่าง: การจัดการเขตเวลาในแอปพลิเคชันทั่วโลก

ลองนึกภาพว่าแอปพลิเคชันของคุณอนุญาตให้ผู้ใช้จากเขตเวลาต่างๆ กำหนดเวลาการประชุมได้ คุณอาจต้องการจัดเก็บเขตเวลาที่ผู้ใช้ต้องการใน JWT Payload เพื่อแสดงเวลาการประชุมอย่างถูกต้อง คุณสามารถเพิ่มการอ้างสิทธิ์ `timeZone` ลงในอินเทอร์เฟซ `JwtPayload`:

interface JwtPayload {
  userId: string;
  email: string;
  roles: string[];
  timeZone: string; // เช่น 'America/Los_Angeles', 'Asia/Tokyo'
  iat: number;
  exp: number;
}

จากนั้น ใน Middleware หรือ Route Handlers ของคุณ คุณสามารถเข้าถึง `req.user.timeZone` เพื่อจัดรูปแบบวันที่และเวลาตามความต้องการของผู้ใช้

4. การใช้ผู้ใช้ที่ยืนยันตัวตนแล้วใน Route Handlers

ใน Route Handlers ที่ได้รับการป้องกันของคุณ ตอนนี้คุณสามารถเข้าถึงข้อมูลของผู้ใช้ที่ยืนยันตัวตนแล้วผ่านออบเจกต์ `req.user` ด้วยความปลอดภัยของชนิดข้อมูลอย่างเต็มที่

import express, { Request, Response } from 'express';
import authenticate from './middleware/authenticate';

const app = express();

app.get('/profile', authenticate, (req: Request, res: Response) => {
  const user = (req as any).user; // หรือใช้ RequestWithUser
  res.json({ message: `Hello, ${user.email}!`, userId: user.userId });
});

ตัวอย่างนี้แสดงวิธีการเข้าถึงอีเมลและ ID ของผู้ใช้ที่ยืนยันตัวตนแล้วจากออบเจกต์ `req.user` เนื่องจากเราได้กำหนดอินเทอร์เฟซ `JwtPayload` TypeScript จึงทราบโครงสร้างที่คาดหวังของออบเจกต์ `user` และสามารถให้การตรวจสอบชนิดข้อมูลและการเติมโค้ดอัตโนมัติ

5. การนำ Role-Based Access Control (RBAC) ไปใช้

สำหรับการควบคุมการเข้าถึงที่ละเอียดมากขึ้น คุณสามารถนำ RBAC ไปใช้โดยอิงตามบทบาทที่จัดเก็บไว้ใน JWT Payload

function authorize(roles: string[]) {
  return (req: RequestWithUser, res: Response, next: NextFunction) => {
    const user = req.user;

    if (!user || !user.roles.some(role => roles.includes(role))) {
      return res.status(403).json({ message: 'Forbidden' });
    }

    next();
  };
}

Middleware `authorize` นี้จะตรวจสอบว่าบทบาทของผู้ใช้รวมถึงบทบาทที่จำเป็นหรือไม่ หากไม่รวม จะส่งคืนข้อผิดพลาด 403 Forbidden

app.get('/admin', authenticate, authorize(['admin']), (req: Request, res: Response) => {
  res.json({ message: 'Welcome, Admin!' });
});

ตัวอย่างนี้ป้องกันเส้นทาง `/admin` โดยกำหนดให้ผู้ใช้ต้องมีบทบาท `admin`

ตัวอย่าง: การจัดการสกุลเงินที่แตกต่างกันในแอปพลิเคชันทั่วโลก

หากแอปพลิเคชันของคุณจัดการธุรกรรมทางการเงิน คุณอาจต้องรองรับหลายสกุลเงิน คุณสามารถจัดเก็บสกุลเงินที่ผู้ใช้ต้องการใน JWT Payload:

interface JwtPayload {
  userId: string;
  email: string;
  roles: string[];
  currency: string; // เช่น 'USD', 'EUR', 'JPY'
  iat: number;
  exp: number;
}

จากนั้น ในตรรกะฝั่งเซิร์ฟเวอร์ของคุณ คุณสามารถใช้ `req.user.currency` เพื่อจัดรูปแบบราคาและทำการแปลงสกุลเงินตามที่จำเป็น

6. Refresh Tokens

JWT ถูกออกแบบมาให้มีอายุสั้น เพื่อหลีกเลี่ยงการบังคับให้ผู้ใช้เข้าสู่ระบบบ่อยครั้ง ให้ใช้ Refresh Tokens Refresh Token คือโทเค็นที่มีอายุยาวนานซึ่งสามารถใช้เพื่อรับ Access Token (JWT) ใหม่ได้โดยไม่ต้องให้ผู้ใช้ป้อนข้อมูลประจำตัวอีกครั้ง จัดเก็บ Refresh Tokens อย่างปลอดภัยในฐานข้อมูลและเชื่อมโยงกับผู้ใช้ เมื่อ Access Token ของผู้ใช้หมดอายุ พวกเขาสามารถใช้ Refresh Token เพื่อขออันใหม่ได้ กระบวนการนี้ต้องดำเนินการอย่างระมัดระวังเพื่อหลีกเลี่ยงช่องโหว่ด้านความปลอดภัย

เทคนิคขั้นสูงสำหรับความปลอดภัยของชนิดข้อมูล

1. Discriminated Unions สำหรับการควบคุมแบบละเอียด

บางครั้ง คุณอาจต้องการ JWT Payload ที่แตกต่างกันโดยอิงตามบทบาทของผู้ใช้หรือประเภทของการร้องขอ Discriminated Unions สามารถช่วยให้คุณบรรลุเป้าหมายนี้ด้วยความปลอดภัยของชนิดข้อมูล

interface AdminJwtPayload {
  type: 'admin';
  userId: string;
  email: string;
  roles: string[];
  iat: number;
  exp: number;
}

interface UserJwtPayload {
  type: 'user';
  userId: string;
  email: string;
  iat: number;
  exp: number;
}

type JwtPayload = AdminJwtPayload | UserJwtPayload;

function processToken(payload: JwtPayload) {
  if (payload.type === 'admin') {
    console.log('Admin email:', payload.email); // สามารถเข้าถึงอีเมลได้อย่างปลอดภัย
  } else {
    // ไม่สามารถเข้าถึง payload.email ได้ที่นี่ เนื่องจาก type เป็น 'user'
    console.log('User ID:', payload.userId);
  }
}

ตัวอย่างนี้กำหนดประเภท JWT Payload สองประเภทที่แตกต่างกันคือ `AdminJwtPayload` และ `UserJwtPayload` และรวมเข้าด้วยกันเป็น Discriminated Union `JwtPayload` พร็อพเพอร์ตี้ `type` ทำหน้าที่เป็นตัวแยกแยะ ทำให้คุณสามารถเข้าถึงพร็อพเพอร์ตี้ได้อย่างปลอดภัยโดยอิงตามประเภทของ Payload

2. Generics สำหรับตรรกะการยืนยันตัวตนที่นำกลับมาใช้ใหม่ได้

หากคุณมีกลไกการยืนยันตัวตนหลายแบบที่มีโครงสร้าง Payload แตกต่างกัน คุณสามารถใช้ Generics เพื่อสร้างตรรกะการยืนยันตัวตนที่นำกลับมาใช้ใหม่ได้

interface BaseJwtPayload {
  userId: string;
  iat: number;
  exp: number;
}

function verifyToken(token: string): T | null {
  try {
    const decoded = jwt.verify(token, JWT_SECRET) as T;
    return decoded;
  } catch (error) {
    console.error('JWT verification error:', error);
    return null;
  }
}

const adminToken = verifyToken('admin-token');
if (adminToken) {
  console.log('Admin email:', adminToken.email);
}

ตัวอย่างนี้กำหนดฟังก์ชัน `verifyToken` ที่รับประเภท Generic `T` ซึ่งขยาย `BaseJwtPayload` สิ่งนี้ช่วยให้คุณสามารถตรวจสอบโทเค็นที่มีโครงสร้าง Payload แตกต่างกัน ในขณะที่ยังคงรับประกันว่าทั้งหมดมีพร็อพเพอร์ตี้ `userId`, `iat` และ `exp` เป็นอย่างน้อย

ข้อควรพิจารณาสำหรับแอปพลิเคชันทั่วโลก

เมื่อสร้างระบบการยืนยันตัวตนสำหรับแอปพลิเคชันทั่วโลก ให้พิจารณาสิ่งต่อไปนี้:

• การแปลภาษา (Localization): ตรวจสอบให้แน่ใจว่าข้อความแสดงข้อผิดพลาดและองค์ประกอบส่วนต่อประสานผู้ใช้ได้รับการแปลสำหรับภาษาและภูมิภาคต่างๆ
• เขตเวลา (Time Zones): จัดการเขตเวลาอย่างถูกต้องเมื่อตั้งค่าเวลาหมดอายุของโทเค็นและแสดงวันที่และเวลาแก่ผู้ใช้
• ความเป็นส่วนตัวของข้อมูล (Data Privacy): ปฏิบัติตามกฎระเบียบความเป็นส่วนตัวของข้อมูล เช่น GDPR และ CCPA ลดปริมาณข้อมูลส่วนบุคคลที่จัดเก็บไว้ใน JWT
• การเข้าถึงได้ (Accessibility): ออกแบบขั้นตอนการยืนยันตัวตนของคุณให้เข้าถึงได้สำหรับผู้พิการ
• ความละเอียดอ่อนทางวัฒนธรรม (Cultural Sensitivity): คำนึงถึงความแตกต่างทางวัฒนธรรมเมื่อออกแบบส่วนต่อประสานผู้ใช้และขั้นตอนการยืนยันตัวตน

สรุป

ด้วยการใช้ประโยชน์จากระบบชนิดข้อมูลของ TypeScript คุณสามารถสร้างระบบการยืนยันตัวตนด้วย JWT ที่แข็งแกร่งและดูแลรักษาได้สำหรับแอปพลิเคชันทั่วโลก การกำหนดประเภท Payload ด้วยอินเทอร์เฟซ การสร้างบริการ JWT ที่มีชนิดข้อมูล การป้องกัน Endpoint API ด้วย Middleware และการนำ RBAC ไปใช้เป็นขั้นตอนสำคัญในการรับรองความปลอดภัยและความปลอดภัยของชนิดข้อมูล โดยพิจารณาถึงข้อควรพิจารณาสำหรับแอปพลิเคชันทั่วโลก เช่น การแปลภาษา เขตเวลา ความเป็นส่วนตัวของข้อมูล การเข้าถึงได้ และความละเอียดอ่อนทางวัฒนธรรม คุณสามารถสร้างประสบการณ์การยืนยันตัวตนที่ครอบคลุมและใช้งานง่ายสำหรับผู้ชมต่างชาติที่หลากหลาย อย่าลืมให้ความสำคัญกับแนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยเสมอเมื่อจัดการกับ JWT ซึ่งรวมถึงการจัดการคีย์ที่ปลอดภัย การเลือกอัลกอริทึม การหมดอายุของโทเค็น และการจัดเก็บโทเค็น โอบรับพลังของ TypeScript เพื่อสร้างระบบการยืนยันตัวตนที่ปลอดภัย ปรับขนาดได้ และเชื่อถือได้สำหรับแอปพลิเคชันทั่วโลกของคุณ